Reverse logistics system for mobile devices and method

ABSTRACT

Technologies for reverse logistics of mobile devices is provided. A returned mobile device is placed in a satchel with a unique identifier. The unique identifier was generated through an in-store return process in which the unique identifier was linked to transactional data associated with the returned mobile device, such as the returned mobile device&#39;s IMEI and return type. The transactional data associated with the returned mobile device is searched as a function of the unique identifier to determine the return type. The appropriate supply chain provisioning location is then determined as a function of the determined return type.

RELATED APPLICATION

This application claims the benefit of U.S. Provisional Application Ser.No. 62/696,400 filed on Jul. 11, 2018, for a “Reverse Logistics Systemfor Mobile Devices and Method,” which is hereby incorporated byreference in its entirety.

TECHNICAL FIELD

This system relates generally to a management and technical platformthat provides consumers, carriers, OEMs and vendors the ability tomanage the entire lifecycle of new and used mobile devices; inparticular, this platform integrates functionality of multipleunderlying systems and device-level diagnostic data to manage the devicelifecycle through acquisition to disposition, in real time, includingsupply chain management, an end-to-end view for carriers and OEMs, andseamless integration of options for the consumer in regards to theconsumer's unique characteristics and relationship within the mobile ecosystem.

BACKGROUND AND SUMMARY

Mobile devices go through a service lifecycle. FIG. 1 illustrates eventsthat often occur during a mobile device's typical lifecycle for avariety of users. As discussed below, there are downsides to theexisting lifecycle shown in FIG. 1, which increase complexity and cancause a poor user experience. For example, a user can be caught in adead end journey in which there is no way to upgrade their device orthere may be gaps in device protection. There can also be difficultiespromoting loyalty among users.

The lifecycle starts when a user acquires a mobile device. There areseveral ways in which this can happen. Some users may purchase a mobiledevice outright, whether a new mobile device or one that is preowned.This type of user is represented in FIG. 1 as BYO (bring your owndevice) 100 and will have already purchased their mobile device upfrontwhen going to a carrier for network service. Some users will finance thepurchase of their mobile device, which could be through the carrier, OEMor other financing entity. This type of user is represented in FIG. 1 asMRO (mobile repayment option) 102. The lifecycle begins for otherdevices when a user upgrades from their existing mobile device, such asby accepting an offer to lease an upgraded mobile device. This type ofuser is represented in FIG. 1 as swap 104.

In the existing lifecycle, there of different types of service optionsavailable depending on the type of user. This creates complexity andconfusion in which users may not know what options are available, andsome services may overlap. These complexities are illustrated in theoptions available to users in FIG. 1. In the example shown, the swapuser 104 has the option of an upgrade service 106, which provides theuser with access to an early upgrade 108 or return 110 if their mobiledevice has a malfunction or breaks. As shown, the MRO user 102 has theoption of a device protection service 112, which provides the user withaccess to return 110 the device or perform an advanced exchange 114,which allows the user to obtain a loaner device when their device isbeing returned. As shown, none of the users have access to get theirphone repaired. Also, the BYO user does not have access to either thedevice protection service 112 or the upgrade service 110. One technicalobstacle to offering these services to the BYO user is that their deviceis unknown to the entities that offer these services, and therefore thedevice could have a preexisting fault or technical error that increasesthe risk for these services. Regardless, the lack of any service optionsfor the BYO user reduces stickiness for the carrier and increasesturnover of BYO users.

In addition to the complexity of potentially overlapping options in theexisting lifecycle, there can be delays in these services that frustrateconsumers. For example, a user of a mobile device for which a deviceprotection claim must be adjudicated, cannot upgrade to a differentmobile device until the claim adjudication is complete, which could takeseveral days. There are multiple technical obstacles to providing anupgrade path while a claim is being adjudicated. For example, the claimprotection service and upgrade service are typical offered by differententities. By way of another example, there are fraud risks to providingan upgraded phone without first receiving a user's existing device ingood working order. Additionally, there are concerns about the impactclaim adjudication can take on the value of the user's existing deviceas time passes, which can reduce profitability if the existing device isresold after repair.

According to one aspect, this disclosure provides a computerized systemof managing events surrounding the lifecycle of used and new mobiledevices. In some embodiments, the system provides a “360 view” thatintegrates a mobile device's service options, such as financing anddevice protection, as well as at the device level regarding potentialhardware/software errors. This provides carriers and/or OEMs with anend-to-end view of consumers, such as claims on device protection plans,repayment issues, utilization of upgrades and/or other information in auser's profile across multiple underlying systems during the device'slifecycle. The system tracks, in some embodiments, multiplecharacteristics of the mobile device, such as tracking of the device'ssale (through multiple potential channels) and distribution through thesupply chain, the device's quality, which could be determined throughdiagnostics (and allow device protection options to BYO users), thedevice's value, which could be forecasted using an algorithm, and thedevice's history. In some embodiments, the system includes a fraudprevention feature. For example, the system could aid in disablingnetwork access to a device that has been traded-in or is subject to aclaim adjudication after activation of an upgraded/replacement device.

The system is configured with business rules to handle certain events.In response to some triggering events, such as a device fault, contractending, promotional offer, etc., the system is configured to seamlesslypresent the user with an integrated view of the plans/services availableto the user, including potentially an integrated view of both financingand device protection options, even though the system must aggregatethese options from multiple underlying systems. This reduces confusionsurrounding what options are available to the user and enhances the userexperience. In some cases, the consumer may be able to customize theinitial options suggested by the system that are available to theconsumer. In this way, the system can reduce confusion by suggesting aninitial set of options available to the consumer, but still allowflexibility for customization.

In some embodiments, a diagnostic tool is installed on the mobile devicethat is configured to detect potential hardware and/or softwareproblems. In addition to triggering the presentation of service options,the diagnostic tool solves a technical problem of offering a BYO useraccess to device protection options. The diagnostic tool allowsproviders of the service options some assurance that the BYO device isin good working order, which enables these service options, such asdevice protection.

Embodiments are contemplated in which the system allows a user tosimultaneously perform a device upgrade at the same time as adjudicatinga device protection claim. These two existing serial processes areperformed in parallel, which speeds the time in which the user obtainsthe upgraded device. These processes can run in parallel paths due to asupply chain management system that provides real time event managementduring the upgrade and device protection claim. This allows the systemto simultaneously track the location of the outbound (upgraded) mobiledevice and the inbound (protection claim) mobile device at the same timebased on the IMEI numbers of the devices. Certain events can betriggered based on this tracking, such as updating in real time the IMEInumber associated with the user's profile responsive to the outbound(upgraded) device activation. Additionally, in some embodiments, thesystem messages the carrier in real time to block the IMEI of theinbound (protection claim) device responsive to activation of theoutbound (upgraded) device activation. This supply chain management inwhich events are tracked and triggered based on IMEI numbers solves atechnical problem associated with potential fraud, and allows the userto receive the upgraded device more quickly. In some cases, the supplychain management determines a location in which to ship the inbound(protection claim) device based on the claim adjudication to morequickly resell the device, which potentially increases the device'sresale price. Accordingly, in some embodiments, the IMEI number ofmobile devices can be tracked throughout the entire lifecycle.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure will be described hereafter with reference to theattached drawings which are given as non-limiting examples only, inwhich:

FIG. 1 is block diagram of existing options available to different typesof mobile device users;

FIG. 2 is block diagram of showing example options available todifferent types of mobile device users according to an embodiment of thepresent invention;

FIG. 3 is a diagrammatic view of an example system for managing thelifecycle of a mobile phone according to an embodiment of the presentinvention;

FIG. 4 is a block diagram of an example device that could be used inconjunction with the system and method according to an embodiment of thepresent invention;

FIG. 5 is a block diagram showing example modules that could be includedin the system according to an embodiment of the present invention;

FIG. 6 is a flowchart of an example process that could be used by thesystem for managing options during the lifecycle of a mobile deviceaccording to an embodiment of the present invention;

FIG. 7 is an example flow chart showing potential actions for managing asupply chain during a mobile device upgrade and a device protectionclaim with the system according to an embodiment of the presentinvention;

FIGS. 8-17 are screenshots showing an example user interface for amobile device user to select potential service options triggered by adiagnostic app on the mobile device according to an embodiment of thepresent invention;

FIGS. 18-25 are screenshots showing an example user interface for amobile device user to select potential service options triggered by anoffer associated with the user's profile according to an embodiment ofthe present invention;

FIGS. 26-31 are screenshots showing an example user interface for amobile device user to select potential service options triggered by adiagnostic app on the mobile device and schedule an in-store pickupaccording to an embodiment of the present invention;

FIG. 32 is an example flow chart showing potential actions for a reverselogistics process when a customer requests service for a mobile devicein a store;

FIG. 33 is an example flow chart showing potential actions for a reverselogistics process upon receiving returned mobile devices; and

FIG. 34 is a diagrammatic view of an example system for validating andsorting returned mobile devices in a reverse logistics process.

Corresponding reference characters indicate corresponding partsthroughout the several views. The components in the figures are notnecessarily to scale, emphasis instead being placed upon illustratingthe principals of the invention. The exemplification set out hereinillustrates embodiments of the invention, and such exemplification isnot to be construed as limiting the scope of the invention in anymanner.

DETAILED DESCRIPTION OF THE DRAWINGS

While the concepts of the present disclosure are susceptible to variousmodifications and alternative forms, specific exemplary embodimentsthereof have been shown by way of example in the drawings and willherein be described in detail. It should be understood, however, thatthere is no intent to limit the concepts of the present disclosure tothe particular forms disclosed, but on the contrary, the intention is tocover all modifications, equivalents, and alternatives falling withinthe spirit and scope of the disclosure.

This invention relates to a computerized system of managing eventssurrounding a lifecycle of a mobile phone. In some embodiments, thesystem provides an integrated view of the mobile device user's profile,including which plans/services to which the user is subscribed and adevice-level view that identifies potential hardware or softwareproblems of the device. This provides carriers and OEMs an end-to-endview of the device history and user service choices, which providesvaluable information regarding users and/or their mobile devices. Forexample, carriers and device OEMs would obtain an integrated view aboutthe device and/or user through the entire lifecycle, such as the numberof device protection claims, payment issues for financing, which typesof triggering events resulted in upgrades, etc. Additionally, thisallows options in the mobile device user's services, including but notlimited to, the mobile device user's financing, device protection, andbuy back/trade in to be triggered using diagnostic tools on the user'sdevice. In addition to triggering service options, the diagnostic toolinstalled on the user's mobile device, solves a technical problem ofoffering a BYO user access to device protection options.

In some embodiments, the system allows a user to simultaneously performa phone upgrade at the same time as filing a device protection claim.These two existing serial processes are performed in parallel, whichspeeds the time in which the user obtains the upgraded device. Theseprocesses can run in parallel paths due to a supply chain managementsystem that provides real time event management during the upgrade anddevice protection claim. This allows the system to simultaneously trackthe location of the outbound (upgraded) mobile device and the inbound(protection claim) mobile device at the same time based on the IMEInumbers of the devices. Certain events can be triggered based on thistracking, such as updating in real time the IMEI number associated withthe user's profile responsive to the outbound (upgraded) deviceactivation. Additionally, in some embodiments, the system messages thecarrier in real time to block the IMEI of the inbound (protection claim)device responsive to activation of the outbound (upgraded) deviceactivation. This supply chain management in which events are tracked andtriggered based on IMEI numbers solves a technical problem associatedwith potential fraud, and allows the user to receive the upgraded devicemore quickly. In some cases, the supply chain management determines alocation in which to ship the inbound (protection claim) device based onthe claim to more quickly resell the device, which potentially increasesthe device's resale price.

FIG. 2 illustrates a lifecycle of a mobile device according to anembodiment of the system, and provides a contrast to the existing mobiledevice lifecycle shown in FIG. 1, which is described above. As shown,there are three example types of user, which are the same usersillustrated in FIG. 1. In this embodiment, the system includes anabstraction layer 200 that connects with multiple underlying systemsrelating to various services available to users, such as buy back/tradein (BBTI), device protection and financing solutions (see FIG. 3). Byhaving access to these systems, the abstraction layer 200 is able topull together offers available for multiple solutions that are specificto the user. In the example shown, the abstraction layer 200 is able topull together information regarding options for replacement 202,upgrade/lease 204, advanced exchange 206 and/or repair 208 of a mobiledevice associated with a user. For example, based on a triggering event,the abstraction layer 200 could provide a user interface from which theuser is presented with options for upgrading, replacement, repair of themobile device specific with the user's profile. The triggering eventcould be a diagnostic tool on the mobile device identifying a potentialhardware/software problem, such as a battery malfunction, or a promotionthat would be applicable to the user, such as based a length of timeleft in the user's contract. This unifies the options for the user in aseamless manner, which increases simplicity and enhances the userexperience.

In the example shown in FIG. 2, each type of user has access of allservice options. This stands in contrast to the lifecycle shown in FIG.1 in which the service options depend on the type of user, and there areoverlapping services. Additionally, in this example, the BYO user 100has access to the same service options as the MRO 102 and swap 104users. There is a technical obstacle to offering this level of serviceoptions to a BYO user due to the BYO device being unknown in quality asto potential hardware and/or software problems. Unlike MRO and swapusers, which start the lifecycle with new mobile devices, a BYO user maystart the lifecycle with a preowned mobile device. In some embodiments,the abstraction layer 200 is able to offer these service levels bycommunicating with a diagnostic tool installed on the BYO device. Thediagnostic tool would be able to identify any potentialhardware/software problems prior to offering the services, and would beused to trigger potential service offers as explained below.

Referring to FIG. 3, there is shown a high level diagrammatic view ofthe abstraction layer 200 connected with a plurality of devices on anetwork. In the example shown, the abstraction layer 200 is configuredto communicate with a supply chain management system 300, a buyback/trade in system 302, a device protection system 304, and afinancing system 306. Although these systems 300, 302, 304, 306 may beoperated by different entities, the abstraction layer 200 is able toextract/update data from these systems using a variety of APIs. Thereare several technical benefits to the abstraction layer integratingthese systems. In the enrollment or renewal of a user, for example, thein-store transaction speed of a carrier and/or OEM will be greatlyincreased. Instead of interacting with separate systems for enrolling acustomer in financing and device protection options, the servicerepresentative can interact with the abstraction layer 200—not moving inand out of separate systems for financing and device protection. Thisapproach is estimated to speed up in-store transactions by at least20-30 minutes.

As shown, the abstraction layer 200 is configured to communicate with aplurality of mobile devices 308 via a network. Accordingly, theabstraction layer 200 allows service options from multiple systems to beseamlessly presented as an integrated view to the user on their mobiledevice 308. The presentation of service options to the user can betriggered in a variety of ways, such as when a user qualifies for aparticular offer or if software installed on the user's mobile deviceidentifies a potential hardware and/or software problem. In thisexample, the mobile devices 308 have installed a diagnostic app that isconfigured to identify potential hardware and/or software problems onthe mobile device. In some embodiments, this could be used to triggerpotential service options available to the user, such as repair,replacement, upgrade, etc., based on the user's profile by extractingdata about the user from the multiple systems 300, 302, 304, 306.Embodiments are contemplated in which the mobile devices 308 may bedevices running the Android™ operating system by Google, Inc. ofMountain View, Calif. or a device running iOS™ operating system by AppleInc. of Cupertino, Calif. on which software has been installed to runone or more methods according to an embodiment of the presentdisclosure. For example, the mobile devices 308 may have an appinstalled that allows the abstraction layer to coordinate with (or isintegrated into) the diagnostic tool to perform actions describedherein. Thus, users may interact with the abstraction layer 200 using anapp installed on the mobile devices 308 that allows an integratedpresentation of service options from the multiple systems 300, 302, 304,306 and perform other actions described herein. In some embodiments,certain functionality of the abstraction layer 200 could be hosted on aweb server and accessed by users via a web browser on the mobile device,such as Safari™ by Apple Inc.

Although this example shows four systems 300, 302, 304, 306 to which theabstraction layer 200 communicates in FIG. 3 for purposes of simplicity,there could be numerous other systems to which the abstraction layer 200is configured to communicate. Likewise, even though only four mobiledevices 308 are shown for purposes of simplicity, there could be moremobile devices (e.g., thousands or millions) to which the abstractionlayer 200 is configured to communicate.

FIG. 4 illustrates a diagrammatic representation of a device on whichthe abstraction layer 200 could execute in the example form of a machine200 that may be programmed with a set of instructions to perform any oneor more of the methods discussed herein. The set of instructions couldbe a computer program stored locally on the device that, when executed,causes the device to perform one or more of the methods discussedherein. In some embodiments, at least a portion of the set ofinstructions could be stored remotely such that, when executed, causesthe device to perform one or more of the methods discussed herein. Inembodiments where the computer program is locally stored, data may beretrieved from local storage or from a remote location via a network.Embodiments are contemplated in which the certain functions of theabstraction layer 200 could be performed on a server and/or mobiledevices 308. The terms “mobile device,” “computer” and “server” shallalso be taken to include any collection of machines that individually orjointly execute a set (or multiple sets) of instructions to perform anyone or more of the methods discussed herein.

The machine 400 illustrated in FIG. 4 includes a processor 402 (e.g., acentral processing unit (“CPU”)), a memory 404, a video adapter 406 thatdrives a video display system 408 (e.g., a liquid crystal display(“LCD”) or a cathode ray tube (“CRT”)), an input device 410 (e.g., akeyboard, mouse, touch screen display, etc.) for the user to interactwith the program, a disk drive unit 412, and a network interface adapter414. Note that various embodiments will not always include all of theseperipheral devices.

The disk drive unit 412 includes a computer-readable medium 416 on whichis stored one or more sets of computer instructions and data structuresembodying or utilized by a computer program 418 performing one or moreof the methods described herein. The computer instructions and datastructures may also reside, completely or at least partially, within thememory 404 and/or within the processor 402 during execution thereof bythe machine 400; accordingly, the memory 404 and the processor 402 alsoconstitute computer-readable media. Embodiments are contemplated inwhich the computer program 418 may be transmitted or received over thenetwork 420 via the network interface device 414 utilizing any one of anumber of transfer protocols including but not limited to the hypertexttransfer protocol (“HTTP”) and file transfer protocol (“FTP”).

While the computer-readable medium 416 is shown in the exampleembodiment to be a single medium, the term “computer-readable medium”should be taken to include a single medium or multiple media (e.g., acentralized or distributed database, and/or associated caches andservers) that store the one or more sets of instructions. The term“computer-readable medium” shall also be taken to include any mediumthat is capable of storing a set of instructions for execution by themachine and that cause the machine to perform any one or more of themethods described herein, or that is capable of storing data structuresutilized by or associated with such a set of instructions. The term“computer-readable medium” shall accordingly be taken to include, butnot be limited to, solid-state memories, optical media, flash memory,and magnetic media.

FIG. 5 illustrates example modules that could be included in the system.In this example, the abstraction layer 200 is configured to operate witha plurality of channels from which users can acquire mobile devices. Asshown, the channels include enterprise 500, retailers 502, operators 504and OEM/auction 506. Although these channels from which users canacquire mobile devices are shown for purposes of simplicity, otherchannels could be provided depending on the circumstances.

There is a plurality of service options offered through these channels500, 502, 504, 506. As shown, the service options offered through thechannels include supply chain solutions 508, reverse product solutions510, buy back/trade in solutions 512, device protection 514,omni-channel 516 and financial solutions 518. The supply chain solutions508 provide tracking, ordering, inventory and other logisticalfunctionality for the channels. The reverse product solutions 510 couldprovide a return functionality for the channels. The buy back/trade insolutions 512 could provide an option for users to sell back theirmobile device or receive a credit value, which could be applied to a newdevice. The device protection 514 could be a service that allowsmalfunctioning or broken devices to be returned or repaired. Theomni-channel option could aid with channels offering delivery of devicesto users upon selection at a sales location. The financial solutions 518could be a service that manages financing and lease options for mobiledevices.

The users may interact with the abstraction layer 200 in a variety ofmanners. In the example shown, the user may access service options forhis/her mobile device using a web portal 520, an interactive voiceresponse system 522, a point of sale integration 524, and/or an app 526installed on the user's mobile device 308. Regardless of how the userinteracts with the abstraction layer 200, the user can be presented withservice options specific to that particular user.

The system may include functionality for inventory management,forecasting, and other supply chain functionality. As shown, the systemincludes modules for planning/forecast 528, VMI/VSO (vendor managedinventory) 530, PLI (product lifecycle management) 532, inventory/priceoptimization 534, and BCRE 536. Other functionality regarding inventorymanagement and other forecasting may be provided depending on thecircumstances.

In the example shown, the abstraction layer 200 includes a plurality ofmodules. As shown, the abstraction layer 200 includes API management538, activity monitoring 540, event processing 542, business rules 544,microservices 546 (e.g., modular services, ESB (enterprise service bus)548, process/workflow 550 and EDI (electronic data exchange) 552. Thesemodules perform certain of the actions, tracking, and event monitoringas described herein.

As shown, the abstraction layer 200 includes a plurality of APIs thatexpose data/services from a plurality of systems. In some embodiments,an API gateway offered from Apigee Corp of Sunnydale, Calif. could beused. In this example, there are APIs to expose data/services for order554 (for ordering mobile devices), inventory 556 (fordetermining/updating device inventory), return 558 (managing returnprocessing), track 560 (tracking location of mobile devices by IMEI),repair 562 (managing repair processing), activation 564 (managingactivation processing), enrollment 566 (managing enrollment processing),adjudication 568 (managing device protection claim adjudicationprocessing), fulfillment 570 (managing processing of order fulfillment),credit check 572 (managing credit check for users), CRM 574 (managingdata associated with user), billing 576 (managing billing processes),fraud 578 (detecting potential fraud), grading 580 (determining qualityand grade of mobile device), diagnostics 582 (identifying potentialfaults in hardware/software on mobile device), user management 584(managing users of mobile devices) and charging 586 (managing chargingof mobile devices). In some embodiments, the abstraction layer 200 couldinclude additional APIs to access additional systems or may not includeeach of these APIs depending on the circumstances. As shown, theabstraction layer 200 is configured to interact with a plurality ofenterprise applications 588 via the APIs. By interacting with theplurality of enterprise applications 588, the abstraction layer 200 isconfigured to integrate multiple service options for users.

FIG. 6 is a flow chart illustrating potential actions that may beperformed upon detection of a fault on the mobile device. As discussedabove, a diagnostic app may be installed on the mobile device that isconfigured to detect potential hardware/software problems with themobile device. The process in FIG. 6 starts with a device problem beingdetected or reported by the user (block 600). FIG. 8 illustrates apotential user interface for an app on the mobile device that allows theuser to interact with the abstraction layer 200. In this example, adiagnostic function is integrated in the app. As shown, the userinterface 800 includes a portion 802 that allows the user to manuallyinitiate a diagnostic test. In the embodiment shown, the user interface800 includes a portion 804 for scheduling automatic periodic diagnostictests. The user interface 800 in some cases may include a portion 806that allows a user to manually report a fault, which is describes belowwith respect to FIGS. 26-31.

Upon receiving a detection or report of a fault, the abstraction layer200 will determine what service options are available to the user. Theseoptions are pulled from multiple systems, including buy back/trade insystem 302, device protection system 304 and/or financing system 306.FIG. 9 illustrates an example user interface 800 upon selecting theportion 802 to initiate a diagnostic test. FIG. 10 shows the exampleuser interface 800 upon detecting one or more faults in the mobiledevice. In this example, the user interface 800 includes a portion 1000that allows a user to determine what options are available based ondetection of a hardware/software problem. Upon selecting this portion1000, the abstraction layer 200 will use the APIs to pull informationabout service options to which the user qualifies. In the example shown,the user is presented with an upgrade option 1100, a replacement option1102, and an option to fix the mobile device 1104 via the user interface800 (Block 604 in FIG. 6). The options and pricing presented to the useris based on that user's particular profile. The user can select optionsas desired as shown in FIGS. 12-17. The process continues with adetermination of user selections (block 606). If the user selects both adevice protection claim due to the device fault and an upgrade option,these will be processed simultaneously (block 608). Otherwise, if theuser only selects a device protection claim, that will be processedaccordingly (block 610).

FIGS. 18-25 illustrate another trigger for showing a user potentialservice options. In this example, the abstraction layer 200 triggers thepresentation of service options based on a predetermined time perioduntil the ends of the user's contract. For example, there could bebusiness rules in the abstraction layer 200 that trigger a notificationto a user based on six weeks (or other predetermined time period) leftin the user's contract. The abstraction layer 200 is able to determinehow much time is left in the user's contract due to communicationthrough APIs with financing systems managing the user. In the embodimentshown, the user is presented with a user interface on the mobile devicewith a notification that there is only six weeks left in the user'scontract. Although a user with a contract is described for purposes ofillustration, this notification could be provided to a BYO user forwhich there is a special lease offer or other type of user. As shown,the user can select between closing the notification (1800) orrequesting to see the offers (1802). FIGS. 19-25 illustration how theuser can select one of the service offers and have their new deviceshipped to a location of their choosing.

FIGS. 26-31 illustrate service options being triggered by a devicefault, similar to the example with respect to FIGS. 8-17. In thisexample, however, the user reports a problem with the device (instead ofthe diagnostic app detecting a potential problem) by selecting the“Report Fault” button 806. As shown, the user interface presents theuser with a plurality of potential faults, such as a battery problem2700, a cracked screen 2702, fault 3 2704, fault 4 2706, to be reported.The user, in this example, can also select to engage with a live chat2708 with a customer representative. In this example, the user hasselected a cracked screen 2702. In response to this selection, theabstraction layer 200 communicates with multiple systems to seamlesslypresent the user with an integrated view of potential upgrade 2800,replacement 2802 and repair 2804 options as shown in FIG. 28. Althoughthe abstraction layer 200 presents these options in an integrated viewof the user, these service options may have been determined bycommunicating with multiple underlying systems, such as the financingsystem 306 for the upgrade offer and the device protection system 304 todetermine the replacement and/or repair options. In this example, theuser has selected the replacement offer 2802. In response, the user ispresented with the closest store for picking up the replacement devicebased on location services of the mobile device. As shown in FIG. 29,the user can select from one of the closest stores or pick anotherstore. FIGS. 30-31 illustrate user selection of a time to pick up thereplacement device, and has an option to save this day/time to theuser's calendar.

FIG. 7 illustrates potential actions of the system for supply chainmanagement during adjudication of a device protection claim and upgrade.In the embodiment shown, the claim adjudication occurs simultaneouslywith the upgrade, which allows the user to receive the upgraded mobiledevice earlier than the existing lifecycle in which claim adjudicationand upgrades are serial processes. There are technical obstacles thatwere overcome as described herein to allow the adjudication and upgradeprocesses to occur in parallel.

In the example shown, the process starts with the user selection of adevice protection claim (or a trade in/buy back) and an upgrade (Block700). As discussed above, the abstraction layer 200 may include a userinterface that allows the user to make these selections by pulling theuser profile on service options from multiple systems through APIs. Uponreceiving this user selection, an outbound device (upgrade device) isshipped to the user without waiting for adjudication of the deviceprotection claim. The abstraction layer 200 may interact with a shippingsystem to track the location of the outbound device based on thedevice's IMEI (international mobile equipment identity) number (Block702). Additionally, the abstraction layer 200 could interact with aninventory system through an API to update inventory levels to show thatthe outbound device is no longer within the warehouse.

In some cases, the abstraction layer 200 may perform grading of theinbound device (protection claim device) to determine what action needsto be performed for the inbound device to be resold. Depending on whataction needs to be performed, the abstraction layer could determine varythe address for shipment of the inbound mobile device (block 704). Forexample, if the screen on the inbound mobile device is cracked, theaddress given by the abstraction layer 200 could be a screen replacementfacility. By way of another example, if the battery of the inboundmobile device is malfunctioning, the address could be a warehouse thatincludes battery replacement services. Regardless, the abstraction layer200 could include business rules that are configured to evaluate theclaim and determine the address for shipment accordingly. By having theaddress be determined based on the warranty claim, this speeds theprocess of fixing the inbound device for resale, which potentiallyincreases the resale price of the inbound device by speeding up theprocess. The location of the inbound device is tracked using the IMEInumber upon reaching the address determined by the abstraction layer(block 706).

The process continues at Block 708 in which the abstraction layer 200monitors for activation of the outbound phone. In response to activationof the outbound phone, the abstraction layer 200 updates the userprofile associated with the outbound phone to change the IMEI associatedwith the user of the outbound phone (block 710). The abstraction layer200 can also, in real time responsive to activation of the outboundphone, message the user's carrier to block the IMEI of the previousdevice from the network (block 712). This aids in preventing fraudcaused by a user keeping both their existing device for which a deviceprotection claim was made and the upgraded device. By blocking the IMEIof the existing device, the user will only have a single device thatfunctions on the network. Although the process in FIG. 7 illustratesactions that can be made responsive to event monitoring for supply chainimprovements, the abstraction system 200 can be used for other eventmonitoring regarding a user based on business rules.

FIGS. 32-34 show an embodiment of the system for processing returns ofmobile devices in a store environment through a reverse logisticsprocess. In some embodiments, the system could be integrated, in wholeor part, into the reverse product solutions 510. In other embodiments,the reverse logistics process could be implemented as a stand-alonesystem separate from the reverse product solutions 510.

Existing store returns of mobile devices are complex and createdifficulties in processing. In existing mobile device returns performedin store, a customer is presented with lengthy paperwork that must befilled out and signed. This paperwork is wrapped around the returnedmobile device and shipped to a warehouse for processing the return.Unfortunately, returned devices received at the warehouse often have thepaperwork filled out incompletely, filled out incorrectly or have thepaperwork missing completely. This results in a lengthy review processto identify the mobile device against the correct customer and programinformation resulting in thousands of “orphan” devices for which thecustomer or program cannot be determined. This makes it problematic tovalidate the return and confirm the eligibility of the customer for anupgrade, repair or other service. Additionally, this review processslows processing of returned mobile devices.

In some embodiments, a customer in a store environment, such as acarrier store, a carrier affiliate store, or other electronics store,will seek a service for their mobile device. For example, the customercould seek a trade-in, a repair/exchange, a lease return, an earlyupgrade, device protection, etc. for their mobile device. The systemaccording to an embodiment of the reverse logistics process will receivea request for a particular service from a customer (step 3200). If notalready installed on the customer's mobile device, a store assistantwill help the customer download a device care app on the customer'smobile device. The device care app will perform certain diagnosticactions on the mobile device and assess the eligibility of the mobiledevice for the service sought by the customer, such as reviewing certainaccount information regarding the program under which the customer isenrolled (steps 3202 and 3204). If the mobile device is not eligible forthe service sought, the customer is informed (step 3206). If thetransaction sought by the customer is validated, the customer iselectronically presented with terms and conditions for their digitalsignature (steps 3208 and 3210). This eliminates the lengthy paperworkin existing mobile device returns.

The store will have a supply of satchels for sending returned mobiledevices to processing locations. The satchels are typically dimensionedto hold a single mobile device. There could be different sizes based onmobile device type, such as a satchel for mobile phones, a satchel fortablets, etc. In some embodiments, the satchels will be padded to reducethe likelihood of damage to the mobile device during transit. In somecases, the satchels could be waterproof or otherwise sealed. Thesatchels will each be marked with a unique identifier. In someembodiments, for example, the unique identifier could be a barcode;other embodiments are also contemplated in which other uniqueidentifiers could be used, such as RFID tags.

The store assistant would obtain a satchel from the supply of satchelsin the store and place the mobile device in the satchel (step 3212). Theunique identifier on the satchel would be scanned, such as with abarcode reader (step 3214). In this way, the unique identifier would belinked with transactional data associated with the mobile device andcustomer (step 3216). Accordingly, the customer account and relatedtransactional information regarding the returned mobile device can bedetermined with the unique identifier. The data linked to the uniqueidentifier could include, but is not limited to, the mobile device'sIMEI, model identification, store location, retail attendantidentification, type of return, customer resolution information,destination identification, validation check information, diagnosticinformation, grading information, and/or a replacement IMEI. In someembodiments, the satchel could include a tear-off tag that could beattached to the mobile device or could be kept by the customer as areference ticket.

This satchel would be placed with a plurality of other satchels forother returned mobile devices (step 3218). The scanning of the uniqueidentifier could electronically trigger a courier pick-up request insome embodiments. The store assistant would process mobile devicereturns in a similar manner until a plurality of satchels are ready forpickup by a courier. This plurality of satchels would be groupedtogether into a package, such as a box or envelope depending on thenumber of satchels, and taken by a courier to a supply chainprovisioning location, such as a warehouse that processes returnedmobile devices (step 3220).

The courier would deliver the package with a plurality of satchels eachcontaining returned mobile devices to a supply chain provisioninglocation, such as a warehouse (step 3300). The package would be openedand each of the satchels would be scanned (step 3302). The system atsupply chain provisioning locations (3400, 3402, 3404) include logic tolookup transactional information regarding the mobile device in thesatchel using the unique identifier that is scanned using an API 3406that exposes at least a portion of the transactional data 3408 from thestore via a network 3410 (step 3304). This allows validation ofeligibilities for the service via the transactional data (step 3306).The mobile device can be sorted and sent to the appropriate supply chainprovisioning location based on the transactional data, such as a supplychain location that handles repairs vs. a location that handlesprocessing of devices for resale on a pre-owned marketplace (step 3308).Thus, this system provides technical advantages by reducing paperworkerrors caused by existing return processes. The system also provides thetechnical advantage of speeding processing of returned mobile devices.

Although the present disclosure has been described with reference toparticular means, materials and embodiments, from the foregoingdescription, one skilled in the art can easily ascertain the essentialcharacteristics of the invention and various changes and modificationsmay be made to adapt the various uses and characteristics withoutdeparting from the spirit and scope of the invention.

What is claimed is:
 1. A reverse logistics method for mobile devices,the method comprising the steps of: determining a unique identifierassociated with a returned mobile device in response to scanning asatchel containing the returned mobile device with an electronic sensor,wherein the unique identifier was generated through an in-store returnprocess in which the unique identifier was linked to transactional dataassociated with the returned mobile device during the in-store returnprocess, wherein the transactional data includes (i) an IMEI of thereturned mobile device and (ii) a return type; searching thetransactional data associated with the returned mobile device as afunction of the unique identifier to determine the return type; anddetermining an appropriate supply chain provisioning location as afunction of the determined return type.
 2. The method of claim 1,wherein the transactional data is accessed via an API framework thatexposes transactional data of a store that initiated the in-store returnprocess.
 3. The method of claim 1, wherein the transactional dataincludes one or more of model identification of the returned mobiledevice, a store location in which the in-store return process occurred,a retail attendant identification, a destination identification,diagnostic information of the returned mobile device, gradinginformation of the returned mobile device, and/or an IMEI of a mobiledevice replacing the returned mobile device.
 4. The method of claim 1,wherein the satchel is dimensioned to receive a single mobile device. 5.The method of claim 1, further comprising validating eligibility of thereturn type based on the transactional data associated with the returnedmobile device.
 6. The method of claim 5, wherein the return type from aplurality of return types.
 7. The method of claim 6, wherein theplurality of return types includes one or more of a trade-in, a repair,a lease return, an early upgrade, and/or device protection.
 8. Themethod of claim 6, wherein the plurality of return types includes afirst return type and a second return type, and wherein determining anappropriate supply chain provisioning location as a function of thedetermined return type comprises determining a first appropriate supplychain provisioning location in response to determining the first returntype and determining a second appropriate supply chain provisioninglocation in response to determining the second return type.
 9. Themethod of claim 1, wherein the electronic sensor is one or more of abarcode reader or a RFID reader.
 10. One or more non-transitory,computer-readable storage media comprising a plurality of instructionsstored thereon that, in response to being executed, cause a computingdevice to: determine a unique identifier associated with a returnedmobile device in response to scanning a satchel containing the returnedmobile device with an electronic sensor, wherein the unique identifierwas generated through an in-store return process in which the uniqueidentifier was linked to transactional data associated with the returnedmobile device during the in-store return process, wherein thetransactional data includes (i) an IMEI of the returned mobile deviceand (ii) a return type; search the transactional data associated withthe returned mobile device as a function of the unique identifier todetermine the return type; and determine an appropriate supply chainprovisioning location as a function of the determined return type. 11.The one or more non-transitory, computer-readable storage media of claim10, wherein the transactional data is accessed via an API framework thatexposes transactional data of a store that initiated the in-store returnprocess.
 12. The one or more non-transitory, computer-readable storagemedia of claim 10, wherein the transactional data includes one or moreof model identification of the returned mobile device, a store locationin which the in-store return process occurred, a retail attendantidentification, a destination identification, diagnostic information ofthe returned mobile device, grading information of the returned mobiledevice, and/or an IMEI of a mobile device replacing the returned mobiledevice.
 13. The one or more non-transitory, computer-readable storagemedia of claim 10, wherein the satchel is dimensioned to receive asingle mobile device.
 14. The one or more non-transitory,computer-readable storage media of claim 10, further comprisingvalidating eligibility of the return type based on the transactionaldata associated with the returned mobile device.
 15. The one or morenon-transitory, computer-readable storage media of claim 14, wherein thereturn type from a plurality of return types.
 16. The one or morenon-transitory, computer-readable storage media of claim 15, wherein theplurality of return types includes one or more of a trade-in, a repair,a lease return, an early upgrade, and/or device protection.
 17. The oneor more non-transitory, computer-readable storage media of claim 15,wherein the plurality of return types includes a first return type and asecond return type, and wherein determining an appropriate supply chainprovisioning location as a function of the determined return typecomprises determining a first appropriate supply chain provisioninglocation in response to determining the first return type anddetermining a second appropriate supply chain provisioning location inresponse to determining the second return type.
 18. The one or morenon-transitory, computer-readable storage media of claim 10, wherein theelectronic sensor is one or more of a barcode reader or a RFID reader.19. A reverse logistics method for mobile devices, the method comprisingthe steps of: performing an in-store return process comprising:inserting a returned mobile device into a satchel dimensioned to receivea single mobile device, wherein the satchel includes a uniqueidentifier; linking the unique identifier with transactional dataassociated with the returned mobile device, wherein the transactionaldata includes (i) an IMEI of the returned mobile device and (ii) areturn type; determining an appropriate supply chain provisioninglocation for the returned mobile device comprising: determining theunique identifier by scanning the satchel with an electronic sensor;searching the transactional data associated with the returned mobiledevice as a function of the unique identifier to determine the returntype; and determining the appropriate supply chain provisioning locationas a function of the determined return type.
 20. The method of claim 19,wherein the transactional data is accessed via an API framework thatexposes transactional data of a store that initiated the in-store returnprocess.